Derived data provider #554
Conversation
Refactored WhereBlockRewriter to prepare it for making the derived parameterization a data provider also
|
Since this PR reformats the SourceCode extensively I would wait for #555 to be implemented. |
|
Hey @leonard84, would it make sense for me to rebase this PR or should we close it? |
|
@paplorinc I'll have to look at this after we merge the spock-2.0 branch, before this it doesn't make sense to invest any work. |
|
@paplorinc many things in this area changed over the last versions with PRs from me. Derived Datavariables are still no data providers, but I think they don't need to be anymore. Accessing previous data variables in later data pipes had many quirks and issues. If I remember correctly, I tried to fix them but in the end came to the conclusion that it is not worth it or not possible. So in 2.0 we made a breaking change and now forbid accessing other data variables due to all the problems and quirks like you could easily prematurely drain iterators, access data providers sooner as expected, behaved differently depending on the concrete code construct used, .... All these points were more confusing than necessary, so we forbid it and now you can only access previous columns in data tables (even across tables in the same where block) or all previous data variables in derived data variables. So at least now it should behave consistent, even if some accidentally half-available functionality was removed. |
Where block elements lack consistency in many cases, e.g.:
b = a + 1) aren't data providersetc.
To make these possible in the future (but even if not), many affected classes and tests were refactored and provided with comments.
Also,
@PendingFeaturetests were added to demonstrate the inconsistent behavior.This commit does not fix these issues, as they proved to be far to complex for a single commit.
Please review the commits separately.
This change is